home *** CD-ROM | disk | FTP | other *** search
/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d8 / zmax100b.arc / MAILER.DOC < prev    next >
Text File  |  1990-08-26  |  7KB  |  181 lines
  1.  
  2.                                 Zmax
  3.                         Mailer Implementation
  4.  
  5.  
  6. LEGAL STUFF
  7. ------------------------------------------------------------------------------
  8.  
  9. The protocol, documentation, and Zmax.c routines are by Mike Bryeans.
  10.  
  11. Zmax  is  NOT public domain. Micro TECH Systems  Retains  ALL RIGHTS TO
  12. THIS PROTOCOL.
  13.  
  14. No  PART  of Zmax may be used in development  of  a  NON-ZMAX protocol.
  15.  
  16. Developers  are  granted  a  license  to  use  Zmax  in  NON-COMMERCIAL
  17. applications and environments ONLY.
  18.  
  19.               A 10 dollar donation is requested to help
  20.               offset development costs and to help with
  21.               the  salaries  of the  technical  support
  22.               person(s).
  23.  
  24. If  you application is intended for use in a program that  is to be sold
  25. commercially, including shareware, you must  apply for a Zmax COMMERCIAL
  26. License.
  27.  
  28. If  you  intend  to  develop  a Zmax  driver  for  USE  in  a commercial
  29. environment, you must apply for a Zmax  COMMERCIAL license.
  30.  
  31. All goverment agents Federal, State, and Local must apply for a Zmax
  32. COMMERICAL license.
  33.  
  34. You  may  NOT modify Zmax specifications.  Zmax  MUST  remain uniform and
  35. only Micro TECH Systems may issue NEW or IMPROVED Zmax specifications.
  36.  
  37. If you have a particular item in mind, submit it along with a modified
  38. Zmax.c (Using our Zmax.c driver code) to Micro  TECH Systems.
  39.  
  40.                          Micro TECH Systems
  41.                          555 North Spring, #39
  42.                          Cape Girardeau Mo. 63701
  43.  
  44.                          Data Number  1-314-334-6359
  45.                          Mailer on-line supporting:
  46.  
  47.                          HTMS and HTMS with Zmax
  48.                          Wazoo
  49.                          Zmax
  50.                          FSC001 (Pure FSC001 only. Binkley, FD, and
  51.                                  D'bridge's versions not supported)
  52.                          SEAlink (Overdrive Supported).
  53.                          UUCP   (Requires Password Authorization,
  54.                                  arrange in advance.)
  55.  
  56.  
  57. FEATURES
  58. ------------------------------------------------------------------------------
  59.  
  60. The features of Zmax include
  61.  
  62.          * non-interference with systems that don't understand the
  63.            handshake
  64.  
  65.          * relatively foolproof method for identifying a remote system
  66.            and establishing a common ground for transmission
  67.  
  68.          * built-in room to expand the capabilities of Zmax without
  69.            having to resort to a kludge
  70.  
  71.          * Faster than normal Zmodem transfers, Handles noisy lines
  72.            better and protects ALL data during a transfer with 32 bit
  73.            CRCs.
  74.  
  75.          * The Zmax protocol requires roughtly 1/2 as much memory as
  76.            Zmodem and my be implemented on systems with 64K of system
  77.            memory. Even those that may not be able to handle receiving
  78.            data and writing to the disk drive at the same time.
  79.  
  80.  
  81.          * Uniform method of implementing Service Requests.
  82.  
  83.          * Full functional code included so all implementations should
  84.            be uniform despite the author.
  85.  
  86.  
  87. USAGE
  88. ------------------------------------------------------------------------------
  89.  
  90. Follow normal Wazoo procedures, but replace all 0xF1's with 0xF6 and
  91. all 0x05 with 0x03. If you do not already have a wazoo driver written,
  92. follow the instructions in FSC-0006.txt and replace the 0xF1 and 0x05
  93. characters as outlined.
  94.  
  95. Use Zmax.c as a guide to coding your sendfile and receive file protocol
  96. sections. No special modifications need to be made to Zmax.c. Zmax in its
  97. original state may be used as a mailer protocol or a BBS protocol.
  98.  
  99. You may wish to code a driver and test it against zmax.exe before moving
  100. the code into your mailer.
  101.  
  102. Feel free to call our CBIS system at the number listed above to test your
  103. mailer implementation.
  104.  
  105. SOME DIFFERENCES
  106. ------------------------------------------------------------------------------
  107.  
  108. Unlike Wazoo, the sender doesn't START a transfer unless he actual has
  109. something to send. If the sender has nothing, then simply go directly to
  110. end of batch send as outlined in the Zmax.c code.
  111.  
  112. Block sizes should range from 2048 bytes at 2400 baud to 8192 at 9600+.
  113. Although testing shows no BIG improvement once you exceed 2048 (even at
  114. 9600), your users will no doubt want the large blocks because their use
  115. to them.
  116.  
  117. Unlike Zmodem, Zmax doesn't automatically start sending when a re-send
  118. request is received. Zmax ackknowledges the request and then waits for
  119. the receivers OK to begin sending again. The receiver will wait until the
  120. line has NOTHING on it before giving that OK. This keeps both the
  121. receiver and sender in perfect sync. It also give noise bursts a chance
  122. to die down rather than attempt to send THROUGH them, which generally
  123. ends up being bad anyway.
  124.  
  125. If you stay to FAR ahead of the receiver, this will cause re-syncs to
  126. take longer.
  127.  
  128. SERVICE REQUESTS - HTMS and ZMAX
  129. ------------------------------------------------------------------------------
  130.  
  131. A service request is a request for an external service not directly
  132. related to the process of sending or receiving files.
  133.  
  134. A service request program can do anything within reason, reason being
  135. the amount of time it can take to do it. The maximum amount of time the
  136. receiver can be forced to wait is 5 minutes.
  137.  
  138. The service request is triggered by the caller sending a file using a
  139. special name XXXXXXXX.SRV. XXXXXXXX being the name of the service. The
  140. file MUST have the file extension of SRV to set it apart from other
  141. files.
  142.  
  143. The contents of the XXXXXXXX.SRV can be anything from special text
  144. formated instructions (passwords, names, etc.) to a binary structure. In
  145. short, the contents or makeup of the XXXXXXXX.SRV is set by the service
  146. program being called.
  147.  
  148. Below are the steps for processing a service request.
  149.  
  150. 1. Mail Session established.
  151.  
  152. 2. Receiver goes into receive loop getting all files, etc. from caller.
  153.  
  154. 3. End of Receive loop, Check for any *.SRV file in the inbound file
  155.    directory.
  156.  
  157. 4. If found, pull off up to 8 characters (from the filename) to identify
  158.    the service being requested. Validate the service (method is up to
  159.    the programmer).
  160.  
  161. 5. If valid, send ENQ to caller who is now waiting for the start of the
  162.    first file. Caller is required to ACK the ENQ. Continue to send until
  163.    the caller ACKS it.
  164.  
  165. 6. Call the service program passing FULL drive, path, and filename
  166.    information so it can locate, and use the XXXXXXXX.SRV file.
  167.  
  168. 7. If Service program wishs to pass back any information, files -
  169.    messages, etc. then it can do so. I personally require the service
  170.    programs to write this information to a XXXXXXXX.RPT file and if it
  171.    exists, I send it and then delete it.
  172.  
  173. 8. Delete the XXXXXXXX.SRV file.
  174.  
  175. 9. Proceed with normal sending, if any.
  176.  
  177. The ENQ was added to force the caller to wait longer than the original
  178. 60 seconds. The processing that goes on during that 5 minute wait is
  179. independent of the Zmax protocol. It was intend for use as a method of
  180. doing service requests but it doesn't have to be.
  181.